Method, device, and computer program for encapsulating and parsing timed media data

ABSTRACT

The invention relates according to one of its embodiments to a method for encapsulating a partitioned timed media data, the partitioned timed media data comprising timed samples, at least one timed sample comprising at least one subsample. The method comprising: obtaining at least one subsample from at least one of the timed samples; creating a first track comprising the at least one obtained subsample; obtaining at least another subsample from the same one of the timed samples; creating a second track comprising said at least another obtained subsample; and generating descriptive metadata, the descriptive metadata comprising a unified descriptor comprising: a first parameter which indicates, when set to 1, that the at least one obtained subsample is a complete frame; and at least a second parameter which specifies coding dependencies between the at least one obtained subsample and the at least another obtained subsample.

FIELD OF THE INVENTION

The invention generally relates to the field of encapsulation andparsing of timed media data, e.g. according to Base Media File Format asdefined by the MPEG standardization organization, to provide a flexibleand extensible format that facilitates interchange, management, editing,and presentation of the media data and to improve stream delivery, inparticular regarding HTTP (HyperText Transfer Protocol) and RTP(Real-time Transport Protocol) streaming of user-selected regions ofinterest in compressed video streams.

BACKGROUND OF THE INVENTION

The International Standard Organization Base Media File Format (ISOBMFF) is a well-known flexible and extensible format that describesencoded timed media data bit-streams either for local storage ortransmission via a network or via another bit-stream delivery mechanism.This file format is object-oriented. It is composed of building blockscalled boxes that are sequentially or hierarchically organized and thatdefine parameters of the encoded timed media data bit-stream such astiming and structure parameters.

This file format can describe various video formats such as SVC(Scalable Video Coding), HEVC (High Efficiency Video Coding) or LayeredHEVC (L-HEVC). According to these video formats, a single or multi-layerpartitioned timed media data such as multi-layer tiled timed media data(e.g. scalable tiled or Multiview tiled video data) comprising timedsamples (e.g. images) are transmitted as a set of several timed mediadata tracks, typically base tile tracks and tile tracks. In amulti-layer variant, the base tile tracks comprise a base layer basetrack and at least one enhancement layer base tile track and the tiletracks comprise base layer tile tracks and enhancement layer tiletracks. Each timed media data track comprises one spatial subsample(e.g. several NAL units or contiguous byte-range in a NAL unit) ofseveral timed samples. Such a set of timed media data tracks allows theselecting, composing, and efficient streaming of single or multi-layerspatial video tiles. Each track can be transmitted from a server deviceto a client device as a set of media segment files. An initializationsegment file can be used to transmit metadata required to decode mediasegment files

According to ISO BMFF file format, samples of a track can be grouped tobe associated to a common set of properties: this is the sample groupingmechanism that involves two boxes: the SampleToGroupBox and theSampleGroupDescriptionBox. Both can be associated by a grouping_typevalue. The track have several boxes and a hierarchy of boxes andsub-boxes to describe their properties in terms of media they contain,in terms of samples they contain, typically the sample table box, and interms of relationships or dependencies with other tracks. The definitionof the boxes above mentioned as well as the definition of sub-boxesincluded in those boxes is described in the document “Draft text ofISO/IEC DIS 14496-15 4th edition, ISO/IEC JTC1/SC29/WG11, W15928,February 2016, San Diego, US” (named “w15928” below). Current boxes ormetadata for tile description may lead to complex and less efficientorganization of the ISO BMFF metadata. In particular, w15928 definesdescriptors for tiles: one is called TileRegionGroupEntry orRectTileRegionGroupEntry with an identifying code ‘trif’ and another oneis called TileSetGroupEntry or UnconstrTileRegionGroupEntry with anidentifying code ‘tsif’. Both are intended to be declared as samplegroup properties, called VisualSampleGroupEntries, in theSampleGroupDescriptionBox. ‘trif’ describes tiles samples in terms ofposition, size, independence with respect to other tiles or not andindicate whether they cover the full video or not. Each trif has aunique identifier. ‘tsif’ builds on top of ‘trif’ to describe set oftiles by aggregating one or more ‘trif’, referenced through theirgroupID. ‘tsif’ also provides coding dependencies list for the tiles,for example when a tile depends on another tile, e.g. when some motionvector to predict a data block of a tile uses a data block from aneighbor tile. As well, when the media is a layered media, a tile in alayer may depend on a tile in another layer: a second list of dependencycan provide this list of dependencies. The notion of tile track is alsodefined and consists in putting in a track only the samples or parts ofsamples that pertain to a selected tile or set of tiles. When there areone or more tile tracks, they can reference a common tile base trackthat contains parameter sets information, i.e. initialization data forthe decoders. These tile tracks are identified with a specific code(sample entry): ‘hvt1’ or ‘lhv1’ (in case of layered media). Even iftile track and trif were designed for easy description and access toindependently decodable tiles (a tile that do not depend on any othertiles, except the one co-located in reference pictures), the parsing ofthese two descriptors is not the most efficient because it requires toparse the tile descriptor, the list of tsif descriptors and to find inthe list of tsif the one containing the information for the tiledeclared in the trif.

Furthermore, in a layered coding context, the tiles from the enhancementlayer will always have dependencies to the full picture or to some tilesin the lower layer(s), which implies:

-   -   either that the independent_idc field of the        TileRegionGroupEntry is always 0, and dependencies are unknown        at the ‘trif’ level (FDIS draft, w15928); or that    -   the independent_idc field only describes per-layer dependencies        (Draft text of ISO/IEC FDIS 14496-15 4th edition, ISO/IEC        JTC1/SC29/WG11, w15640), in which case dependencies to the lower        layer(s) are unknown at the ‘trif’ level.

In either cases, in order to find the tiles dependencies, one needs toinspect the TileSetGroupEntry and find a tile set composed of exactlythat tile; the tile set will then give the proper dependencies:

-   -   dependencies applicable for all NALUs regarding the slice and/or        NALU type    -   optionally, dependencies only applicable for IRAP NALUs, in        order to accommodate for cases where the higher layer uses        references from the lower layer(s) only on IRAP picture,        typically at the beginning of the GOP.

As can be seen from the above discussion, describing inter-layer tileddependencies in layered HEVC is possible with the current DIS text, butrequires an additional level of indirection between TileSetGroupEntryand TileRegionGroupEntry. Although these tile descriptions are usuallyconstant and can be made default sample group description in tiletracks, this extra complexity is not very useful.

To solve these issues, there is provided an efficient data organizationand track description scheme suitable especially for handling spatialtiles, scalable layers and multiple views in Layered HEVC formulti-layer video streams. This ensures that the result of the ISO BMFFparsing is more efficient and adapted to single and/or multi layer HEVC.

SUMMARY OF THE INVENTION

It is a broad object of the invention to remedy the shortcomings of theprior art as described above.

According to a first aspect of the invention there is provided a methodfor encapsulating a partitioned timed media data, the partitioned timedmedia data comprising timed samples, at least one timed samplecomprising at least one subsample, the method comprising:

obtaining at least one subsample from at least one of the timed samples;

creating a first track comprising the at least one obtained subsample;

obtaining at least another subsample from the same one of the timedsamples;

creating a second track comprising said at least another obtainedsubsample; and

generating descriptive metadata, the descriptive metadata comprising aunified descriptor comprising: a first parameter which indicates, whenset to 1, that the at least one obtained subsample is a complete frame;and at least a second parameter which specifies coding dependenciesbetween the at least one obtained subsample and the at least anotherobtained subsample.

According to a second aspect of the invention there is provided a methodfor parsing a partitioned timed media data, the partitioned timed mediadata comprising timed samples, at least one timed sample comprising atleast one subsample, the media data being encapsulated so as to includea first track comprising at least one subsample obtained from at leastone of the timed samples and a second track comprising at least anothersubsample obtained from the same one of the timed samples, anddescriptive metadata comprising a unified descriptor including a firstparameter which indicates, when set to 1, that the at least one obtainedsubsample is a complete frame, and at least one second parameter whichspecifies coding dependencies between the at least one obtainedsubsample and the at least another obtained subsample;

the method comprising obtaining the unified descriptor of theencapsulated media data and employing the first and second parametersincluded in the unified descriptor to identify, for a desired subsample,the or each other subsample on which the desired subsample depends.

This advantageously makes the parsing of a partitioned timed media dataless complex as subsamples (e.g. tiles) dependencies can be obtaineddirectly from the unified descriptor.

The invention also provides according to other aspects devices andcomputer programs for encapsulating and parsing partitioned timed mediadata.

Since the present invention can be implemented in software, the presentinvention can be embodied as computer readable code for provision to aprogrammable apparatus on any suitable carrier medium. A tangiblecarrier medium may comprise a storage medium such as a floppy disk, aCD-ROM, a hard disk drive, a magnetic tape device or a solid statememory device and the like. A transient carrier medium may include asignal such as an electrical signal, an electronic signal, an opticalsignal, an acoustic signal, a magnetic signal or an electromagneticsignal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present invention will become apparent tothose skilled in the art upon examination of the drawings and detaileddescription. It is intended that any additional advantages beincorporated herein.

Embodiments of the invention will now be described, by way of exampleonly, and with reference to the following drawings in which:

FIG. 1, comprising FIGS. 1a, 1b, and 1c , illustrates examples of tilesand slice segments in an HEVC bit-stream;

FIG. 2, comprising FIGS. 2a and 2b , illustrates an example ofencapsulating tiles in multiple tracks;

FIG. 3, comprising FIGS. 3a, 3b, and 3c , illustrates different examplesof configurations of HEVC scalable bit-streams;

FIG. 4 illustrates a temporal pipe of tiles selected by a user to bedisplayed;

FIG. 5 illustrates the structure and features of the unified tiledescriptor;

FIG. 6 shows two alternative examples of the codec-agnostic part;

FIG. 7 illustrates another embodiment for the unified tile descriptor toaddress specific tile-based use case;

FIG. 8 illustrates various rendering use cases of tile tracks;

FIG. 9 illustrates a parsing process by a media player to retrieve tileinformation; and

FIG. 10 represents a block diagram of a server or a client device inwhich steps of one or more embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the invention can apply, for example, to the video formatknown as HEVC.

According to the HEVC standard, images can be spatially divided intotiles, slices, and slice segments. In this standard, a tile correspondsto a rectangular region of an image that is defined by horizontal andvertical boundaries (i.e., rows and columns). It contains an integernumber of Coding Tree Units (CTUs). Therefore, tiles can be efficientlyused to identify regions of interest by defining, for example, positionsand sizes for regions of interest. However, the structure of an HEVCbit-stream as well as its encapsulation as Network Abstract Layer (NAL)units are not organized in relation to tiles but are based on slices.

In the HEVC standard, slices are sets of slice segments, the first slicesegment of a set of slice segments being an independent slice segment,that is to say a slice segment whose general information stored within aheader does not refer to that of another slice segment. The other slicesegments of the set of slice segments, if any, are dependent slicesegments (i.e. slice segments whose general information stored within aheader refers to that of an independent slice segment).

A slice segment contains an integer number of consecutive (in rasterscan order) Coding Tree Units. Therefore, a slice segment can be of arectangular shape or not and so, it is not suited to represent a regionof interest. It is encoded in an HEVC bit-stream for a slice segmentheader followed by slice segment data. Independent and dependent slicesegments differ by their header: since a dependent slice segment dependson an independent slice segment, the amount of information of its headeris smaller than the one of an independent slice segment. Bothindependent and dependent slice segments contain a list of entry pointsin the corresponding bit-stream that are used to define tiles or asentropy decoding synchronization points.

FIG. 1, comprising FIGS. 1a, 1b, and 1c , illustrates examples of tilesand slice segments. More precisely, FIG. 1a illustrates an image (100)divided into nine portions by vertical boundaries 105-1 and 105-2 andhorizontal boundaries 110-1 and 110-2. Each of the nine portionsreferenced 115-1 to 115-9 represents a particular tile.

FIG. 1b illustrates an image (100′) containing two vertical tilesdelimited by vertical boundary 105′. Image 100′ comprises a single slice(not referenced) containing five slice segments, one independent slicesegment 120-1 (represented with hatched lines) and four dependent slicesegments 120-2 to 120-5.

FIG. 1c illustrates an image (100″) containing two vertical tilesdelimited by vertical boundary 105″. The left tile comprises two slices:a first slice containing one independent slice segment (120′-1) and onedependent slice segment (120′-2) and a second slice also containing oneindependent slice segment (120′-3) and one dependent slice segment(120′-4). The right tile comprises one slice containing one independentslice segment (120′-5) and one dependent slice segment (120′-6).

According to the HEVC standard, slice segments are linked to tilesaccording to rules that may be summarized as follows (one or bothconditions have to be met):

-   -   all CTUs in a slice segment belong to the same tile (i.e. a        slice segment cannot belong to several tiles); and    -   all CTUs in a tile belong to the same slice (i.e. a tile may be        divided into several slice segments provided that each of these        slice segments only belongs to that tile).

For the sake of clarity, it is considered in the following that one tilecontains one slice having only one independent slice segment. However,embodiments of the invention can be carried out with otherconfigurations like the ones illustrated in FIGS. 1b and 1 c.

As mentioned above, while tiles can be considered as an appropriatesupport for regions of interest, slice segments are the entities thatare actually put in NAL units for transport over a communication networkand aggregated to form access units (i.e. coded picture or samples atfile format level).

It is to be recalled that according to the HEVC standard, the type of aNAL unit is encoded in two bytes of the NAL unit header that can bedefined as follows:

nal_unit_header ( ) {  forbidden_zero_bit  nal_unit_type  nuh_layer_id nuh_temporal_id_plus1 }

NAL units used to code slice segments comprise slice segment headersindicating the address of the first CTU in the slice segment thanks to aslice segment address syntax element. Such slice segment headers can bedefined as follows:

slice_segment_header ( ) {  first_slice_segment_in_pic_flag if(nal_unit_type >= BLA_W_LP && nal_unit_type <=  RSV_IRAP_VCL23)  no_output_of_prior_pics_flag  slice_pic_parameter_set_id if(!first_slice_segment_in_pic_flag){  if(dependent_slice_segments_enabled_flag)    dependent_slice_segment_flag   slice_segment_address  } If(!dependent_slice_segment_flag){  [...]

Tiling information is provided in a PPS (Picture Parameter Set) NALunit. The relation between a slice segment and a tile can then bededuced from these parameters.

While spatial predictions are reset on tile borders (by definition),nothing prevents a tile to use temporal predictors from a different tilein the reference frame(s). Accordingly, to build independent tiles,motion vectors for the prediction units are advantageously constrainedinside a tile, during encoding, to remain in the co-located tile in thereference frame(s). In addition, the in-loop filters (deblocking andsample adaptive offset (SAO) filters) are preferably deactivated on thetile borders so that no error drift is introduced when decoding only onetile. It is to be noted that such a control of the in-loop filters isavailable in the HEVC standard. It is set in slice segment headers witha flag known as loop_filter_across_tiles_enabled_flag. By explicitlysetting this flag to zero, the pixels at the tile borders cannot dependon pixels that fall on the border of the neighbor tiles. When these twoconditions relating to motion vectors and to in-loop filters are met,tiles can be considered as “independently decodable tiles” or“independent tiles”.

When a video bit-stream is encoded as a set of independent tiles, thisthen enables a tile-based decoding from one frame to another without anyrisk for missing reference data or propagation of reconstruction errors.This configuration then makes it possible to reconstruct only a spatialpart of the original video that can correspond, for example, to theregion of interest illustrated in FIG. 4 (comprising tiles 3 and 7).Such a configuration can be indicated as supplemental information in avideo bit-stream so as to indicate that tile-based decoding is reliable.

FIG. 2, comprising FIGS. 2a and 2b , illustrates an example ofencapsulating tiles in multiple tracks.

FIG. 2a illustrates an example of tile configuration. For the sake ofillustration, it comprises four tiles (tile 1 to tile 4), the size ofeach tile being of 310 pixel width and 256 pixel height.

FIG. 2b illustrates an example of encapsulating the four tilesrepresented in FIG. 2a into independent tracks according to the MPEG-4file format. As illustrated, each tile is encapsulated in its own track,enabling efficient data addressing and leading to encapsulating thevideo as 5 tracks: four tile tracks referenced 201, 202, 203, and 204for encapsulating each tile and one parameter set track 210 (alsoreferred to as base track in the description) common to all tile tracks.

The description of each tile track (201, 202, 203, and 204) is based ona TileRegionGroupEntry box (identified by the ‘trif’ reference), such asTileRegionGroupEntry box 206.

Here, the ‘trif’ boxes use the default sample grouping mechanism (withattribute default_sample_description_index=1, noteddef_sample_descr_index=1 in the Figure) to associate all the samples ofthe tile track to the appropriate TileRegionGroupEntry orTileSetGroupEntry. For example, the NAL units 221 corresponding to tile1 are described in track 1 (referenced 201) in the TileRegionGroupEntrybox 206.

There is no need here for a NALUMapEntry descriptor since all samples ina given track map to the tile described by this track. References 221and 222 designate, respectively, data chunks that contain data for tile1 and tile 4 from time 1 to time S (duration of the media file or mediasegment in case of track fragments).

Actually the track samples are not conventional video samples since inthis embodiment, they are tile samples: a sample stored in a tile trackis a complete set of slices for one or more tiles, as defined in ISO/IEC23008-2 (HEVC). This excludes parameter sets, SEI messages, and othernon-VCL NAL units. An HEVC sample stored in a tile track is consideredas a sync sample if the VCL NAL units in the sample indicate that thecoded slices contained in the sample are Instantaneous Decoding Refresh(IDR) slices, Clean Random Access (CRA) slices, or Broken Link Access(BLA) slices. As such, they do not have the same sizes as conventionalsamples would have: according to the example of FIG. 2a , conventionalHEVC samples would have a size of 640×512 pixels while here, the HEVCsamples stored in each tile track have a size of 320×256 pixels. Inorder to avoid ambiguity at parsing time, the tile samples are signaledwith a new type of VisualSampleEntry descriptor: the HEVCTileSampleEntrydescriptor, such as HEVCTileSampleEntry descriptor 205 associated withtrack 1 (designated with 4-letter code ‘hvt1’).

Formally, the sample entries of HEVC video tracks are HEVCSampleEntriesdeclared in the sample description box of each track header. Here, sincemultiple tracks representing the same video stream are used, each tiletrack comprises an indication that the samples in the track are actuallysamples of a sub part of a complete video stream, indicating that thesesamples are samples of the HEVCTileSampleEntry type (each ‘hvt1’ box inthe Sample Description box ‘stsd’ of each track). Then, the decoding ofa tile track does not involve any layout operation, and the tile isdecoded at the same place in the video decoder memory as if all tileswere decoded. Then the layout information in the track header of a tiletrack are set identical to the track header information of theassociated base track as identified by the ‘tbas’ track reference type.Otherwise, the tile track should be ignored. Additionally, visualinformation in a tile track does not differ from the visual informationin its related base track. In particular, there is no need to redefineinformation like clean aperture box ‘clap’ or pixel sample aspect ratio‘pasp’ in the sample description.

For the sample description type ‘hvt1’, neither the samples in the tiletrack or the sample description box can contain PS, SPS or PPS NALunits. These NAL units must be in the samples or in the sampledescription box of the track containing the base layer (as identified bythe track references) in case of scalability or in a dedicated tracksuch as dedicated track 210 in FIG. 2 b.

Sub-sample and sample grouping defined for regular HEVC samples have thesame definitions for an HEVC tile sample. The dependencies between theparameter set/base track 210 and the tile tracks are preferablydescribed using a track reference box “tref” of type ‘scal’ referenced211 (or any other four-byte code signaling an extractor-based tilingdependency).

HEVC video coding standard supports multi-layer video encoding formulti-view or scalable applications. In this case, a given layer can beused as reference data for one or more other layers.

FIG. 3, comprising FIGS. 3a, 3b, and 3c , illustrates different examplesof configurations of HEVC scalable bit-streams.

FIG. 3a is an example of a spatially scalable video bit-streamcomprising a base layer 300 and an enhancement layer 305. Enhancementlayer 305 is encoded as a function of base layer 300. In such a videobit-stream format, there exists a picture to picture dependency sincenone of the base and enhancement layers contains tiles.

FIG. 3b illustrates another example of a scalable video bit-streamcomprising a base layer 310 and an enhancement layer 315. According tothis example, enhancement layer 315 is a tiled enhancement layercomprising, in particular, tile 320. In such a video bit-stream format,there exists a tile to picture dependency since tiles of the enhancementlayer depend on the base layer.

FIG. 3c still illustrates another example of a scalable video bit-streamcomprising a base layer 325 and an enhancement layer 330. According tothis example, base layer 325 is a tiled base layer comprising, inparticular, tiles 335 and 340, and enhancement layer 330 is a tiledenhancement layer comprising, in particular, tile 345 and tile set 350.Base layer 325 can be spatially enhanced with enhancement layer 330. Insuch a video bit-stream format, there exists a tile to tile dependencysince tiles of the enhancement layer depend on tiles of the base layer.There also exists a tile set to tile dependency since a tile set of theenhancement layer depends on tiles of the base layer. For the sake ofillustration, tile 345 depends on tile 340 and tile set 350 depends ontile 335. Other dependencies may exist such as a tile to tile setdependency or a tile set to tile set dependency.

It is to be noted that similar configurations exist for a SNR scalablelayer which may or may not be tiled on top of a base layer which alsomay or may not be tiled.

FIG. 4 illustrates a temporal pipe of tiles selected by a user to bedisplayed. More precisely, FIG. 4 represents a first video frame n and asecond video frame n+m (where n and m are integer values), each of thefirst and second video frames comprising twelve tiles numbered 1 to 12.For the sake of illustration, only the third and seventh tiles are to bedisplayed (as denoted with bold lines) amongst these twelve tiles. Videoframes n and n+m belong to a series of consecutive frames correspondingto a given temporal period. Therefore, the third and seventh tiles ofeach frame from frame n to frame n+m are displayed consecutively.

However, the data of a video bit-stream conforming to the standard mp4file format are organized as temporal samples that correspond to fullframes. Accordingly, it is required to access several small byte rangesfor each frame when particular spatial areas of these frames are to beaccessed during a given period of time as described above by referenceto FIG. 4. This is inefficient in HTTP streaming in terms of the numberof generated requests and in terms of data overhead. It is also lessefficient for bit-stream extraction for RTP streaming because itrequires multiple small file seeking operations.

Therefore, to provide a more efficient access in compressed videos forROI streaming, the timed media data bit-stream is to be reorganized sothat data of a particular tile are organized as a contiguous byte range(forming a pipe) for a given time period (i.e. a set of consecutiveframes).

Accordingly, when only a spatial sub-part of video frames is to bedisplayed, only pipes of tiles corresponding to the selected spatialarea must be downloaded (for instance tiles 3 and 7 in FIG. 4) using oneHTTP request per pipe and per time period. Similarly, in RTP streaming,a server can extract more efficiently bigger data chunks from a sourcesuch as a hard disk, corresponding to a pipe of tiles.

According an embodiment of the invention, there is provided a unifiedtile descriptor to handle single tile and set of tiles for single andmulti-layer video tracks in a transparent way, whatever the tile isindependently decodable or not. In this embodiment, a tile correspondsto one subsample obtained from at least one timed sample (e.g. images).

FIG. 5 provides the structure and features of the unified tiledescriptor. It is a specific VisualSampleGroupEntry and is intended tobe described as a property in the SampleGroupDescriptionBox ofgrouping_type ‘trif’, associated or not to a SampleToGroupBox with thesame grouping_type. The various parameters contained in this unifiedtile descriptor are described below.

-   -   groupID is a unique identifier for the tile region (either a        rectangular region in an image or non-rectangular region but        without holes) described by this group. Value 0 is reserved for        special use in the ‘nalm’ box.    -   independent_idc specifies the coding dependencies between this        tile region and other tile regions in the current picture and in        reference pictures, whether from the same layer or not. This        flag takes the following values:    -   If independent_idc equals 0, the coding dependencies between        this tile region and other tile regions in the same picture or        previous pictures are given by the list of        dependencyTileGroupID. If dependency_tile_count is 0, these        dependencies are unknown.    -   If independent_idc equals 1, there are no temporal dependencies        between this tile region and the other tile regions with        different groupID in any reference pictures in the same layer        but there can be coding dependencies between this tile and the        tile region with the same groupID in the reference pictures in        the same layer, or with different groupID in other layers. If        the associated sample this tile belongs to is a random access        sample as defined for this HEVC layer, the coding dependencies        between this tile region and other tile regions in lower layers        are given by the list of irap_dependencyTileGroupID; if        irap_dependency_tile_count is 0, these dependencies are unknown.        If the associated sample this tile belongs to is not a random        access sample as defined for this HEVC layer, the coding        dependencies between this tile region and other tile regions in        lower layers are given by the list of dependencyTileGroupID; if        dependency_tile_count is 0, there are no coding dependencies        between this tile region and other tile regions in any reference        picture of other layers for non random access samples.    -   If independent_idc equals 2, there are no coding dependencies        between this tile region and any other tiles in the reference        pictures.    -   Value 3 is reserved.    -   full_picture, when set, indicates that this tile region is        actually a complete picture, in which case region_width and        region_height shall be set to the layer luma size, and        independent_flag shall be set to 1. This allows expressing        dependencies between tiles of a layer to a non-tiled layer, the        later using a ‘trif’ sample group with full_picture parameter        set to 1. When tile_group is set to 1 and full_picture is set to        1, the union of tile regions identified by tileGroupID list        shall completely cover (no holes, no overlap) the layer luma        plane.    -   filtering_disable, when set, indicates that no post-decoding        filtering operation on this tile region require access to pixels        adjacent to this tile region, i.e. bit-exact reconstruction of        the tile region is possible without decoding the adjacent tiles.    -   tile_group, when set to 1, indicates that this tile region is        the result of visually grouping the tile regions identified by        tileGroupID. This allows describing non rectangular tile        regions. When set to 0, the tile region shall be used to        describe a rectangular, dense rectangle (i.e. without holes) of        HEVC tiles.    -   has_dependency_list: when set to 1, indicates that a list of        dependencies is present. If set to 0, dependency_tile_count is        assumed to be 0.    -   has_irap_dependency_list: when set to 1, indicates that a list        of dependencies for random access samples is present. If set to        0, irap_dependency_tile_count is assumed to be 0.    -   horizontal_offset and vertical_offset give respectively the        horizontal and vertical offsets of the top-left pixel of the        rectangular region represented by the tile region, relative to        the top-left pixel of the picture, in luma samples of the base        region. When tile_group is set to 1, these values are inferred        to be the minimum values of horizontal_offset, vertical_offset        of the tiles regions identified by tileGroupID.    -   region_width and region_height give respectively the width and        height of the rectangular region represented by the tile region,        in luma samples of the base region. When tile_group is set to 1,        these values are inferred to be the width and height of the        region described by the union of tiles regions identified by        tileGroupID.    -   tile_count gives the number of tiles regions from which this        tile region is defined.    -   tileGroupID indicates the tile region groupID value (as defined        by a TileRegionGroupEntry) of a tile region that belongs to this        tile region.    -   dependency_tile_count indicates the number of tile regions in        the dependency list.    -   dependencyTileGroupID gives the identifier of a tile region (as        defined by a TileRegionGroupEntry) that this tile region depends        on.    -   irap_dependency_tile_count and irap_dependencyTileGroupID        specify an additional list of tile region(s) this tile region        depends on when the sample this tile region belongs to is a        random access sample as defined for this HEVC layer.

For tile tracks as defined in HEVC and L-HEVC standards, the base regionused in the TileRegionGroupEntry is the size of the picture to which thetile belongs. Note that for L-HEVC streams using spatial scalability andtiling on both the base and enhancement layers, the TileRegionGroupEntrysample descriptions of the base layer will give coordinates expressed inluma samples of the base layer, while the TileRegionGroupEntry sampledescriptions of the enhancement layer will give coordinates expressed inluma samples of the enhancement layer.

The unified tile descriptor reduces the number of sample groups presentin SampleTableBox ‘stbl’ or in track fragments ‘traf’. It alsosimplifies the description of inter-layer dependencies of HEVC tilessince only one descriptor has to be parsed, whatever a single tile or atile set is described. It also simplifies the encapsulation process formp4 writer.

As an alternative embodiment and for specific coding configurations, wemay change the signification of the groupID to allow it to describe thesame tile across different layers. For example, when grid of tiles isaligned across layers (all tiles have the same positions in bothlayers). This can be the case for two SNR scalability layers forexample. This way, a single tile descriptor can be declared in thetrack, for the two layers, instead of two tile descriptors, one perlayer.

Another embodiment consists in reserving another value for theindependent_idc flag to indicate that a tile or tile set is independentin its layer but has dependencies in other layers, but only on the sameco-located tile or tile set. This could avoid the explicit declarationof the dependencies list, even with multi-layer video.

Another embodiment combining the tile_group flag and the reserved bit soas to form a 2-bit parameter, can consist in signaling in the tiledescriptor whether the tile is single tile (00 in binary), a tile set(01) or a tile subset (10), the value (11) being reserved. The new pointhere is the handling of encoding configuration where one slice containsmore than one tile. Using the new 2-bit parameter and when set to 10 (inbinary), it also allows to indicate some coding dependencies for tilesinside a slice. This can be useful when one wants to extract for storageor streaming only a tile in the slice.

FIG. 9 illustrates the parsing of a media file containing the tiledescriptor according to the invention. This tile descriptor can beexploited by a ISOBMFF parser and more generally by media players toinform users on presence of region of interests in a video (908) or toidentify data for a region of interest to transmit these data or storethese data in another file. For that, the player opens a media file andstarts by building a list of tracks declared in the file in 901. Itselects the video track, looking at the track handler declared in thetrack boxes in 902 and for these video tracks get the sample table boxin 903. It can then determine the kind of samples contained in the videotracks in 904, in particular whether they correspond to tile tracks ornot (test 904). If it is the case it means a tile descriptor isavailable for the track. It is read in 905 to get tile position andsizes, then dependency is read from the tile descriptor in 906 and if itindicated that the tile is independently decodable (test 907; fromvarious dependencies flags or from independent_idc flag as explainedabove). If independently decodable, the tile can be exploited (display,storage, transmission, extraction, for user interface or information . .. ) in 908. If the video track is not a video track, the mp4 parserlooks for a tile descriptor in the list of sample group descriptionboxes in 909. If one is found it is processed in steps 905 to 908 andnext video track is processed in 910 and iterates over 903. The tileprocessing terminated when no more video tracks are available in 910.

Another embodiment for the tile descriptor is to have a codec-agnosticpart and a codec-specific part. Two alternative examples of thecodec-agnostic part are shown on FIG. 6. The first alternative 601defines the new TileRegion sample group entry, identified by a specificreserved code, for example ‘tile’. The TileRegion sample groupdescription is used to describe the spatial relationship between videoor image media tracks. It allows identifying that decoded samples of atrack spatially correspond to a given rectangular area in another track.It contains the following parameters:

-   -   region_id is a unique identifier for all tile region sample        group descriptions that relate to the same visual region.    -   horizontal_offset and vertical_offset give respectively the        horizontal and vertical offsets of the top-left coordinate of        the rectangular region represented by the rectangular tile        region, relative to the top-left coordinate of the reference        region. The reference region is the region formed by the union        of all sample group description of type ‘tile’ with the same        region_id.    -   region_width and region_height give respectively the width and        height of the rectangular region represented by the rectangular        tile region, in integer coordinates.

The units used to describe the region size are arbitrary units and maycorrespond to video pixel resolution, but don't have to.

This new TileRegion sample group description is used to describe thespatial relationship between video or image media tracks. It allowsidentifying that decoded samples of a track spatially correspond to agiven rectangular area in another track. This can be useful for mediafiles or live media streams encapsulating multiple video tracks. Forexample a TV program where several views are proposed, this can be used,depending on the current camera arrangement in displays (position ofthese different videos, for example picture in picture or video invideo) to know where a specific content associate to one of the videotracks is located. This can be useful for example if video gadgets haveto be superimposed or if subtitles have to be associated to the video.In general, a video track “A” may use a track reference of type “tile”to a video track “B” in order to indicate that the content of “A” is arectangular region of the content of “B”. The description of thelocation of this area is given by TileGroupEntry sample groupdescriptions like in 401.

The other alternative 602 contains the following parameters:

-   -   full_picture parameter (for example on one bit) that when set to        1, indicates that this rectangular tile region is actually a        complete picture, in which case region_width and region_height        shall be set to the width and height of the reference region.        Semantics for this field may be further restricted by derived        specifications, like for example codec specific file formats.    -   The template parameter is reserved but can be overridden by        other specifications like for example codec specific file        formats.    -   groupID is a unique identifier for all tile region sample group        descriptions that relate to the same visual region. Value 0 is        reserved for special use by derived specifications. Derived        specification may override the semantics of this field.    -   horizontal_offset and vertical_offset give respectively the        horizontal and vertical offsets of the top-left pixel of the        rectangular region represented by the rectangular tile region,        relative to the top-left pixel of the reference region. For the        context of this specification, the reference region is the        region formed by the union of all sample group description of        type ‘trif’ with the same groupID. Semantics for this field may        be further restricted by derived specifications like for example        codec-specific file formats.    -   region_width and region_height give respectively the width and        height of the rectangular region represented by the rectangular        tile region, in luma samples.

Alternative embodiments exist for these two variants, in particularadding place holders (or reserved bits) at the end to providecodec-specific information, like for example the dependency information(independent_idc) flag of the unified tile descriptor or the variousdependency lists.

FIG. 7 illustrates another embodiment for the unified tile descriptor701 to address specific tile-based use case. In particular, it allows toaddress video sample organization as on 702 where each tiled videosample has a region of interest 703 and other tiles corresponding tobackground of the video (704). The new hidden flag proposed in the tiledescriptor 701 allows to encapsulate less important tiles, here thebackground ones in a dummy or virtual tile descriptor. Typically, thetile descriptor for the region of interest contains the sizes of theregion 703 and its positions in the video 702. But for background tiles,it is more efficient to define one rectangular region and mark it ashidden or not intended to be displayed, setting this hidden flag to 1.This informs a parser that position and size information is not reliableand not intended to be used. As such, instead of defining one or morerectangular regions with multiple unified tile descriptors, only onedummy tile descriptor is sufficient. Moreover, it allows to describe anyarbitrarily shaped region in the image, even with holes. This is usefulfor bit-stream extraction when a player needs to extract only the regionof interest. Since bit-stream extraction is a subtraction process, themp4 parser or multimedia player needs to rapidly identify the track orthe sample or the NAL units (resp. when tiles are in tile track, mappedthrough samples groups and mapped via NALU mapping) to discard so as toobtain the region of interest. Identifying a dummy tile descriptor, itwould get the information that related track or samples or NAL units canbe safely discarded from the bit-stream. An alternative to the use ofthis specific flag or parameter can be to indicate that when sizes areset to 0, then it is a dummy tile descriptor and then a region notintended to be displayed. An additional parameter can also be added tothe unified tile descriptor to annotate the region, using for example anadditional string parameter (not represented on FIG. 7). This additionalstring parameter can take: “ROI”, “background” text description. Anotheradvantage of dummy tile descriptor is that when content creator preparesa media presentation for streaming, the DASH packager in charge oftransforming the ISOBMFF file into streamable DASH segments has theindication that, for example a tile track is a dummy one and this onewould automatically not be exposed at DASH level.

It has to be noted that the tile_group parameter of the unified tiledescriptor can be used to control the access granularity in terms oftiles. For example, one can decide to encapsulate video samples as on702 into a first tile describing the region of interest 703 as a singlerectangular region (thus not providing a finer access than the region:no access to each tile composing this region of interest is provided).This, when tile tracks are exposed in streaming manifest for tile-basedtransmission or adaptation can save description size in the streamingmanifest and makes adaptation easier for DASH clients (less choices andconfiguration to compare and select).

When tiles are encapsulated in their own tracks, they refer to a basetile track to access initialization information, typically the parametersets. There are cases where all tiles share the same set of propertieswith the base tile track: sync sample, dependency, sap types, ‘rap’ and‘roll’, likely most of the defined sample groups (except tiling). Sometables cannot be omitted in a track as their absence already has meaning(namely sync sample table). In order to avoid duplicating this info inNxM tile tracks (N being the number of tiles in horizontal dimension andM the number of tiles in the vertical dimension), a new mechanism forsample grouping is introduced:

“Samples from a tile track inherit any property defined through samplegroups for the corresponding sample in the base track, unless a samplegroup description of the same type is given in the tile track. Forexample, if the base tile track has a ‘roll’ sample group descriptionand the tile track does not, the roll distance for samples in the tiletrack is the same as the roll distance for samples in the base track.More generally, when a sample group description (resp. sample to group)of a given grouping_type value is not present in a tile track but ispresent in the base tile track, the sample group description (respsample to group) of the given grouping_type of the base track applies tothe samples of this tile track. This can reduce redundancy of somesample groups in multi-track files.

To have this behavior explicit, SampleToGroup andSampleToGroupDescription are modified so as to indicate this informationto the tracks they are related to (or tracks using them through thetrack reference mechanism). This can be done with a new version of theseboxes and a new parameter, called for example shareable that takes abinary value: 1 means shareable (i.e. dependent tracks not redefining itwill directly reuse the box) or 0 (i.e. dependent tracks not redefiningit will not be able to share directly the box). Another embodiment forthis new parameter is to have different values of inheritance, like forexample “public”, “protected”, “private” with the following semantics:

-   -   “public” means that all tracks with same media type inherits the        sample group and/or sample group description boxes from the        track declaring these new sample group boxes.    -   “Protected” means that only the track referencing the track        declaring these new sample group boxes as a base track, for        example vie ‘tile’, ‘sbas’, ‘scal’ or ‘tbas’ can inherit the        so-declared sample groups and properties.    -   “private” means that no track can reuse these new sample group        and/or description boxes.

To make easier the tile-based streaming, the tile tracks from theISOBMFF file or segment files have to be exposed in a streaming manifestor playlist. In a preferred embodiment, we consider the MPEG DASHprotocol for adaptive streaming on HTTP.

When constraining the HEVC parameter sets to be identical amongdifferent versions of the stream, it is possible to combine the tilesfrom these versions into a conformant HEVC bit-stream, decodable using asingle decoder, thereby opening the possibilities to adapt the bitrateon a tile-basis, rather than on a complete sequence level, as shown onFIG. 8 (in 820). FIG. 8 illustrates some usages of tile tracks fortile-based rendering: tile-based adaptation 820, tile-based view 825 ortile-based transcoding and rendering as a full-picture 830. Each tile ofeach quality can typically be packaged in a single track containing onlytile-related Video Coding Layer NAL units, and most non Video CodingLayer (non-VCL) NAL units would be in a dedicated track, called “basetile track”.

In such case, reconstruction of the full Access Unit (AU) can beachieved based either on extractors from the base tile track to tiletracks, or on implicit AU reconstruction rules (mostly VCL NALUconcatenation rules) from the base track to tile tracks.

It is to be noted that if only a subset of the complete tiles of an HEVCsequence should be decoded then un-needed tile tracks can be discardedand/or some extractors can be ignored while decoding the HEVC sequence;this would however not rebuild a complete image as shown in FIG. 8 on825 part where only one of the two tiles is selected (black area on theright of 825 for which no data is received).

The HEVC file format also defines an extractor format giving rules torewrite part of the bit-stream while copying other parts. A typical usecase for this is to provide an extractor track that extracts a tile of aN×M motion-constrained tiled HEVC bit-stream into a conformant,non-tiled HEVC bit-stream with the same resolution as the extractedtile, allowing full-frame playback of a single tile without having tostrip part of the reconstructed picture as shown on 830 on FIG. 8.Obviously, accessing only the tile of interest through DASH rather thanthe entire bit stream would save quite a lot of bandwidth and isinteresting for ROI inspection using DASH or any adaptive streamingprotocol.

In order to perform tile-based access to the video bit-stream, the basetile track 810 and the tile tracks 811 to 814 are each mapped to anMPEG-DASH Representation in its own AdaptationSet, where the tilelocation is given by an SRD descriptor at the AdaptationSet level. Eachtile track Representation then has a dependencyId attribute towards the“base tile track”, allowing locating and loading all non-VCL data forthat track. Two approaches are then possible in order to reconstruct thecomplete video from all the tile tracks, as illustrated on FIG. 8 anddescribed in the tables of the Appendix.

In the first approach, corresponding to 820 rendering and Table 1, alltile tracks 811 to 814 Representations and the base tile track 810Representation share the same initialization segment (same physical fileon media server called “v_base.mp4”), repeated in streaming manifestwith each tile track Representation and with the base tile track. Thebase tile tracks 811 to 814 are described as Representations with thecodecs attribute set to ‘hvt1’ followed by profile/tier/levelinformation. The DASH client is responsible for fetching in order thedifferent tiles of interest (from the corresponding AdaptationSetsand/or Representations of the DASH MPD), for example selected by a userfrom a user interface. The user interface can for example reflect theSRD information obtained by DASH client during MPD parsing and candisplay the grid of tiles somewhere on the user interface. Each cell ofthe grid of tiles can be clickable to select one or a set of tiles. Eachcell in the grid of tiles is then related to an AdaptationSet declaredin the manifest. The DASH client then knows that clicking a cell or aselection of cells means selection of the one or more relatedAdaptationSets. This simplifies the design of the MPD, but howeverrequires special processing at the DASH client to identify that alltiled Representations (Representation for tile tracks) belong to thesame coded object, by analyzing dependency indications (for example thedependencyId attribute in DASH), mime type and SRD parameters. Theso-selected tile tracks (through the AdaptationSets or Representationsfor example) are rendered as they are placed in the original file: i.e.the reconstructed video bit-stream for a selected tile is rendered inits position given in the SRD and from the position in the originalvideo sequence as shown in 820. When selecting multiple tiles to beplayed together, then the initialization segment may be requested twice.But the HTTP stack of the DASH client will already have this segment inits cache and the request would then not be issued again. It is to benoted that the Representation for the base tile track 810 in the Table 1has specific SRD annotation with object_width and object_height set to0. This is an indication that should prevent DASH clients to select thisbase tile track alone. Indeed, it is declared in the manifest so thattile tracks depending on it can obtain initialization information. Thetrick in the description of Table 1 is that the initialization segmentis declared in each Representation of the tile tracks but in terms ofencapsulation it is placed in the base tile track. In this scenario, theDASH client needs to identify that all adaptation sets withRepresentation containing tracks of type “hvt1” and the same SRDsource_id are a single video object, and should not instantiate multiplevideo decoders. This differs from “regular” logic in DASH (with orwithout SRD) where each AdaptationSet maps to a single decoder, but isactually very close to multi-view use cases (each view in a givenadaptation set) or a spatial scalable use case where UHD enhancement andHD base layer would be in separate adaptation set.

In the second approach, represented in Table 2 in the appendix, eachtile track Representation (or the base tile track 810 Representation)has its own initialization segment, typically including only the tiletrack and the base tile track (signaled with SRD object_width andobject_height set to 0 to avoid selection by a DASH client). Thisdescription complies with the DASH rule on different initializationsegments for dependent Representations. In addition to theAdaptationSets for tile and base tile tracks, an extra “aggregation”AdaptationSet (for example using extractors as in composite track) isused to describe the set of tile tracks composing the full video foreach quality; the Representations in this set would have their owninitialization segment including all tile tracks, and dependencyId toall tile tracks Representation; the media segments of thisRepresentation will be empty, as all data is carried in the base trackand the tile tracks. This design is a bit heavier but does not requirespecific processing of the DASH client in order to reconstruct the fullvideo. However, this design does not allow expressing adaptation rulesof the tile tracks Representation, as the aggregated Representation (theones with codecs=“hev2 . . . ” on Table 2) explicitly gives the list ofdependencies that have to be followed by the DASH engine. In this case,the selected tile track is rendered as a new compliant HEVC bit-streamresulting from high-level syntax modification (for example bytranscoding video sizes and rewriting the position of the coding treeblocks for the tile) to render the tile or a set of tile as a new fullvideo as shown in 830.

The condition on different initialization segments for theRepresentations in Table 2 comes from the DASH specification on handlingof initialization segments in case of dependent Representations.However, since the base track cannot be used without the tile tracks,and a single tile track with its base being an incomplete HEVCbit-stream, enforcing different initialization segments is relevant inthe tiling case. This design does not allow expressing adaptation rulesof the tile tracks representation, as each aggregated representationexplicitly gives the list of dependencies that have to be followed bythe DASH engine. One approach to fix this problem is to declare in themanifest all the possible tile combinations in the “aggregated”AdaptationSet, but this becomes heavy when using 3×3 or more tiling. Forexample, a two alternative bitrates for a 3×3 tiling would lead to 512combinations.

Table 3 is another example of a DASH description of tile trackscontaining the proposed tile descriptor. In order to perform full HEVCreconstruction from a tile without accessing the entire tiledbit-stream, each tile of the video stream can be packaged in a singletrack of type hvt1, and extraction instruction would be in an additionaltrack of type hev2/hvc2 (since the resulting extracted bit-stream is aconformant HEVC bit-stream). Both tracks can be packaged in a singlemedia file (for example ISOBMFF file).

Table 4 is another example, reusing description of table 3 and adding anAdaptationSet for the full video that described a 2×1 tiling as on 800on FIG. 8.

A preferred embodiment is illustrated in Table 5. This description ofHEVC tile tracks embedding the proposed tile descriptor for tile-basedadaptation keeps the MPD light. For that, the Adaptation Sets containingrepresentations of codec type ‘hvt1’ shall only contain representationof type ‘hvt1’. The Adaptation Sets containing Representations having acodecs (the “codecs” attribute in Table 5) type ‘hvt1’ shall contain anSRD descriptor as SupplementalProperty. These SRD parameters reflect theparameters stored in the tile descriptor ‘trif’ of the tile track. Thebase tile track of an ‘hvt1’ Representation (Representation with@codecs=‘hvt1 . . . ’) is given by the last entry in the dependencyIdlist that indicates a Representation with codec type hev2/hvc2. All‘hvt1’ representations sharing the same base have identical switchingand addressing properties as their base tile track: initializationsegment, bitstreamSwitching, startWithSAP, segment duration orSegmentTimeline, startNumber, $Time$ or $Number$ addressing. The “basetile track” is declared in a dedicated AdaptationSet containing anessential property SRD descriptor, with object_x, object_y,object_width, object_height all being set to 0. Several tilerepresentations, as indicated by the ‘hvt1’ codec type in the MPD, canbe gathered in a single AdaptationSet if and only if they have the samedependencyId and correspond to the same tile, as indicated by the SRDdescriptor in the AdaptationSet. Adaptation Sets containingrepresentations of codec type ‘hvt1’ can then be decoded using a singleHEVC decoder if and only if provided that they share the same base tiletrack, as identified by their dependencyId and that they belong to thesame SRD group, as identified by the source_id of the SRD descriptor.This description and organization of the streaming manifest avoidsdefining one “aggregation” AdaptationSet per tile and allows miwingtiles at different qualities and/or ROI inspection use cases.

In the Table 5 example, each tile track is accessible as a singleconformant HEVC video through the Representations N_K_x, (N being thetile number and K the quality level) while at the same time the completevideo can be recomputed by feeding all selected ‘hvt1’ representationsto the HEVC decoder associated with SRD sharing the same source_idvalue. (1 in the example of Table 5).

An alternative embodiment, instead of relying on ‘hvt1’ codec conditionsis to define a new DASH descriptor, for example an EssentialPropertywith schemeIdUri equal to “urn:mpeg:dash:video:tile:2016” for theAdaptationSet containing tile representations (or in the Representationitself) and another descriptor, for example with“urn:mpeg:dash:video:basetile:2016” schemeIdUri value for the “base tiletrack” (the new descriptor is placed in the Representation or theAdaptationSet) describing this base tile track. This makes the manifestless HEVC_centric (i.e. extensible to other video compression formats)since no more relying on the specific sample entry ‘hvt1’. This followsthe generalization of the tile descriptor as a generic tile descriptorindependent from the coding or compression format.

FIG. 10 represents a block diagram of a server or a client device 1000in which steps of one or more embodiments may be implemented.

Preferably, the device 1000 comprises a communication bus 1002, acentral processing unit (CPU) 1004 capable of executing instructionsfrom program ROM 1006 on powering up of the device, and instructionsrelating to a software application from main memory 1008 after thepowering up. The main memory 1008 is for example of Random Access Memory(RAM) type which functions as a working area of CPU 1004 via thecommunication bus 1002, and the memory capacity thereof can be expandedby an optional RAM connected to an expansion port (not illustrated).Instructions relating to the software application may be loaded to themain memory 1008 from a hard disk (HD) 1010 or the program ROM 1006 forexample. Such software application, when executed by the CPU 1004,causes the encapsulation step described with reference to FIGS. 1 and 2to be performed in the server.

Reference numeral 1012 is a network interface that allows the connectionof the device 1000 to the communication network 1014. The softwareapplication when executed by the CPU 1004 is adapted to react torequests received through the network interface and to provide datastreams and requests via the network to other devices.

Reference numeral 1016 represents user interfaces to display informationto, and/or receive inputs from, a user.

It should be pointed out here that, as a variant, the device 1000 formanaging the reception or sending of multimedia bit-streams can consistof one or more dedicated integrated circuits (ASIC) that are capable ofimplementing the method as described with reference to FIG. 9. Theseintegrated circuits are for example and non-restrictively, integratedinto an apparatus for generating or displaying video sequences and/orfor listening to audio sequences.

Embodiments of the invention may be embedded in a device such as acamera, a smartphone, or a tablet that acts as a remote controller for aTV, for example to zoom into a particular region of interest. They canalso be used from the same devices to have personalized browsingexperience of a TV program by selecting specific areas of interest.Another usage of these devices by a user is to share selected sub-partsof his/her preferred videos with other connected devices. They can alsobe used in smartphone or tablet to monitor what happens in a specificarea of a building placed under surveillance provided that thesurveillance camera supports the generation part of this invention.

Naturally, in order to satisfy local and specific requirements, a personskilled in the art may apply to the solution described above manymodifications and alterations all of which, however, are included withinthe scope of protection of the invention as defined by the followingclaims.

APPENDIX

TABLE 1 <MPD>  <Period >  <AdaptationSet maxWidth=“1280”maxHeight=“640” >   <EssentialPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,   0, 0, 0, 0”/>  <SegmentTemplate initialization=“v_base.mp4” ... />    <Representationid=“1” mimeType=“video/mp4” codecs=“hev2.1.6.L186.0” width=“1280”height=“640” />  </AdaptationSet>  <AdaptationSet maxWidth=“640”maxHeight=“640” ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014”   value=“1, 0, 0, 640, 640”/>  <SegmentTemplate initialization=“v_base.mp4” ... />   <Representationid=“1_1” mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0” dependencyId=“1”bandwidth=”128000”/>   <Representation id=“1_2” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1” bandwidth=”768000”/> </AdaptationSet>  <AdaptationSet maxWidth=“640” maxHeight=“640” ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014”   value=“1,640, 0, 640, 640”/>   <SegmentTemplate initialization=“v_base.mp4” .../>   <Representation id=“2_1” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1” bandwidth=”128000”/>  <Representation id=“2_2” mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0”dependencyId=“1” bandwidth=”768000”/>  </AdaptationSet>  </Period></MPD>

TABLE 2 <MPD> <Period >  <AdaptationSet maxWidth=“1280”maxHeight=“640” >  <EssentialPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,0,0”/> <SegmentTemplate initialization=“v_base.mp4” ... />  <Representationid=“1” mimeType=“video/mp4” codecs=“hev2.1.6.L186.0” width=“1280”height=“640”/>  </AdaptationSet>  <AdaptationSet ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,640,640”/> <SegmentTemplate initialization=“v_tile1.mp4” ... />  <Representationid=“1_1” mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0” dependencyId=“1”bandwidth=”128000”/>  <Representation id=“1_2” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1” bandwidth=”768000”/> </AdaptationSet>  <AdaptationSet ...>  <Supplemental PropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,640,0,640,640”/> <SegmentTemplate initialization=“v_tile2.mp4” ... />  <Representationid=“2_1” mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0” dependencyId=“1”bandwidth=”128000”/>  <Representation id=“2_2” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1” bandwidth=”768000”/> </AdaptationSet>  <AdaptationSet ...>  <Supplemental PropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,1280,640”/> <SegmentTemplate initialization=“v_all.mp4” ... />  <Representationid=“A_1” mimeType=“video/mp4” codecs=“hev2.1.6.L186.0” dependencyId=“1_12_1”/>  <Representation id=“A_2” mimeType=“video/mp4”codecs=“hev2.1.6.L186.0” dependencyId=“1_1 2_2”/>   <Representationid=“A_1” mimeType=“video/mp4” codecs=“hev2.1.6.L186.0” dependencyId=“1_22_1”/>   <Representation id=“A_2” mimeType=“video/mp4”codecs=“hev2.1.6.L186.0” dependencyId=“1_2 2_2”/>  </AdaptationSet> </Period> </MPD>

TABLE 3 <MPD>  <Period >  <AdaptationSet maxWidth=“1280”maxHeight=“640” >   <EssentialPropertyschemeIdUri=“urn:mpeg:dash:srd:2014”   value=“1,0,0,0,0”/>  <SegmentTemplate initialization=“v_base.mp4” ... />   <Representationid=“1” mimeType=“video/mp4”   codecs=“hev2.1.6.L186.0” width=“1280”height=“640”/>  </AdaptationSet>  <AdaptationSet ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014”  value=“1,0,0,640,640”/>   <SegmentTemplateinitialization=“v_tile1_x.mp4” ... />   <Representation id=“1_1”mimeType=“video/mp4”   codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/>  <Representation id=“1_2” mimeType=“video/mp4”  codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/>  </AdaptationSet> <AdaptationSet ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014”   value=“1,640,0,640,640”/>  <SegmentTemplate initialization=“v_tile2_x.mp4” ... />  <Representation id=“2_1” mimeType=“video/mp4”  codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/>   <Representation id=“2_2”mimeType=“video/mp4”   codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/> </AdaptationSet>  </Period> </MPD>

TABLE 4 <MPD> <Period >  <AdaptationSet maxWidth=“1280”maxHeight=“640” >   <EssentialPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,0,0”/>  <SegmentTemplate initialization=“v_base.mp4” ... />   <Representationid=“1” mimeType=“video/mp4” codecs=“hev2.1.6.L186.0” width=“1280”height=“640”/>  </AdaptationSet>  <AdaptationSet ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014”value=“1,0,0,640,640”/>   <SegmentTemplate initialization=“v_tile1.mp4”... />   <Representation id=“1_1” mimeType=“video/mp4”codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/>   <Representation id=“1_2”mimeType=“video/mp4” codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/> </AdaptationSet>  <AdaptationSet ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,640,0,640,640”/>  <SegmentTemplate initialization=“v_tile2.mp4” ... />   <Representationid=“2_1” mimeType=“video/mp4” codecs=“hev2.1.6.LXXX.0”dependencyId=“1”/>   <Representation id=“2_2” mimeType=“video/mp4”codecs=“hev2.1.6.LXXX.0” dependencyId=“1”/>  </AdaptationSet> <AdaptationSet ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,1280,640”/>  <SegmentTemplate initialization=“v_all.mp4” ... />   <RepresentationmimeType=“video/mp4” codecs=“hev2.1.6.L186.0” dependencyId=“1_1 2_1”/>  <Representation mimeType=“video/mp4” codecs=“hev2.1.6.L186.0”dependencyId=“1_1 2_2”/>   <Representation mimeType=“video/mp4”codecs=“hev2.1.6.L186.0” dependencyId=“1_2 2_1”/>   <RepresentationmimeType=“video/mp4” codecs=“hev2.1.6.L186.0” dependencyId=“1_2 2_2”/> </AdaptationSet></Period> </MPD>

TABLE 5 <MPD> <Period >  <AdaptationSet maxWidth=“1280”maxHeight=“640” >   <EssentialPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,0,0”/>  <SegmentTemplate initialization=“v_base.mp4” ... />   <Representationid=“1” mimeType=“video/mp4” codecs=“hev1.1.6.L186.0” width=“1280”height=“640”/>  </AdaptationSet>  <AdaptationSet ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014”value=“1,0,0,640,640”/>   <SegmentTemplate initialization=“v_base.mp4”... />   <Representation id=“1_1” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1”/>   <Representation id=“1_2”mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0” dependencyId=“1”/> </AdaptationSet>  <AdaptationSet ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,640,0,640,640”/>  <SegmentTemplate initialization=“v_base.mp4” ... />   <Representationid=“2_1” mimeType=“video/mp4” codecs=“hvt1.1.6.L186.0”dependencyId=“1”/>   <Representation id=“2_2” mimeType=“video/mp4”codecs=“hvt1.1.6.L186.0” dependencyId=“1”/>  </AdaptationSet> <AdaptationSet ...>   <SupplementalPropertyschemeIdUri=“urn:mpeg:dash:srd:2014” value=“1,0,0,640,640”/>  <SegmentTemplate initialization=“v_tile1_x.mp4” ... />  <Representation id=“1_1_x” mimeType=“video/mp4”codecs=“hev2.1.6.LXXX.0” dependencyId=“1_1”/>   <Representationid=“1_2_x” mimeType=“video/mp4” codecs=“hev2.1.6.LXXX.0”dependencyId=“1_2”/>  </AdaptationSet>  <AdaptationSet ...>  <SupplementalProperty schemeIdUri=“urn:mpeg:dash:srd:2014”value=“1,640,0,640,640”/>   <SegmentTemplateinitialization=“v_tile2_x.mp4” ... />   <Representation id=“2_1_x”mimeType=“video/mp4” codecs=“hev2.1.6.LXXX.0” dependencyId=“2_1”/>  <Representation id=“2_2_x” mimeType=“video/mp4”codecs=“hev2.1.6.LXXX.0” dependencyId=“2_2”/>  </AdaptationSet></Period> </MPD>

1-17. (canceled)
 18. A method for generating one or more media filesbased on video data, the method comprising: obtaining the video data;generating a plurality of tile tracks each containing video data of atleast one tile region; generating a TileRegionGroupEntry to be used todescribe a tile region of the video data and including a descriptor,which, when set to 1, indicates that a dependency list is present insaid TileRegionGroupEntry, and when set to 0, indicates that thedependency list is not present in said TileRegionGroupEntry, wherein thedependency list includes ‘dependency_tile_count’ which indicates anumber of tile regions in the dependency list and DependencyTileGroupIdthat gives a group identifier of a tile region that the tile regiondepends on; and generating the one or more media files based on theplurality of tile tracks and said TileRegionGroupEntry.
 19. The methodaccording to claim 18, wherein the TileRegionGroupEntry further includesa flag regarding whether the descriptor to be used for decoding processis present in said TileRegionGroupEntry.
 20. The method according toclaim 19, wherein the flag, when set to 0, indicates the descriptor ispresent in saidTileRegionGroupEntry, and when set to 1, indicates thedescriptor is not present in saidTileRegionGroupEntry.
 21. The methodaccording to claim 18, wherein said TileRegionGroupEntry is included ina SampleGroupDescriptionBox for giving information about thecharacteristics of sample groups of the video data.
 22. A method forprocessing one or more media files based on video data, the methodcomprising: receiving the one or more media files comprising (i) aplurality of tile tracks each contains video data of at least one tileregion and (ii) a TileRegionGroupEntry to be used to describe a tileregion of the video data, wherein the TileRegionGroupEntry includes adescriptor, when set to 1, indicates that a dependency list is presentin said TileRegionGroupEntry, and when set to 0, indicates that thedependency list is not present in said TileRegionGroupEntry, and whereinthe dependency list includes ‘dependency_tile_count’ indicates a numberof tile regions in the dependency list and DependencyTileGroupId thatgives a group identifier of a tile region that the tile region dependson; and representing video data of one or more tile regions by referringsaid TileRegionGroupEntry.
 23. The method according to claim 22, whereinthe TileRegionGroupEntry further includes a flag regarding whether thedescriptor to be used for decoding process is present in saidTileRegionGroupEntry.
 24. The method according to claim 22, wherein saidTileRegionGroupEntry is included in a SampleGroupDescriptionBox forgiving information about the characteristics of sample groups of thevideo data.
 25. A device for generating one or more media files based onvideo data, the method comprising: a hardware processor; and a memorystoring one or more programs configured to be executed by the hardwareprocessor, the one or more programs including instructions for:obtaining the video data; generating a plurality of tile tracks eachcontains video data of at least one tile region; generating aTileRegionGroupEntry to be used to describe a tile region of the videodata and including a descriptor, when set to 1, indicates that adependency list is present in said TileRegionGroupEntry, and when set to0, indicates that the dependency list is not present in saidTileRegionGroupEntry, wherein the dependency list includes‘dependency_tile_count’ indicates a number of tile regions in thedependency list and DependencyTileGroupId that gives a group identifierof a tile region that the tile region depends on; and generating the oneor more media files based on the plurality of tile tracks and saidTileRegionGroupEntry.
 26. The device according to claim 25, wherein theTileRegionGroupEntry further includes a flag regarding whether thedescriptor to be used for decoding process is present in saidTileRegionGroupEntry.
 27. The device according to claim 25, wherein saidTileRegionGroupEntry is included in a SampleGroupDescriptionBox forgiving information about the characteristics of sample groups of thevideo data.
 28. A device for processing one or more media files based onvideo data, the method comprising: a hardware processor; and a memorystoring one or more programs configured to be executed by the hardwareprocessor, the one or more programs including instructions for:receiving the one or more media files comprising (i) a plurality of tiletracks each contains video data of at least one tile region and (ii) aTileRegionGroupEntry to be used to describe a tile region of the videodata, wherein the TileRegionGroupEntry includes a descriptor, when setto 1, indicates that a dependency list is present in saidTileRegionGroupEntry, and when set to 0, indicates that the dependencylist is not present in said TileRegionGroupEntry, and wherein thedependency list includes ‘dependency_tile_count’ indicates a number oftile regions in the dependency list and DependencyTileGroupId that givesa group identifier of a tile region that the tile region depends on; andrepresenting video data of one or more tile regions by referring saidTileRegionGroupEntry.
 29. The device according to claim 28, wherein theTileRegionGroupEntry further includes a flag regarding whether thedescriptor to be used for decoding process is present in saidTileRegionGroupEntry.
 30. The device according to claim 28, wherein saidTileRegionGroupEntry is included in a SampleGroupDescriptionBox forgiving information about the characteristics of sample groups of thevideo data.
 31. A non-transitory computer-readable storage mediumstoring a program for causing a computer to execute a method comprising:obtaining video data; generating a plurality of tile tracks eachcontains video data of at least one tile region; generating aTileRegionGroupEntry to be used to describe a tile region of the videodata and including a descriptor, when set to 1, indicates that adependency list is present in said TileRegionGroupEntry, and when set to0, indicates that the dependency list is not present in saidTileRegionGroupEntry, wherein the dependency list includes‘dependency_tile_count’ indicates a number of tile regions in thedependency list and DependencyTileGroupId that gives a group identifierof a tile region that the tile region depends on; and generating the oneor more media files based on the plurality of tile tracks and saidTileRegionGroupEntry.
 32. The medium according to claim 31, wherein theTileRegionGroupEntry further includes a flag regarding whether thedescriptor is to be used for decoding process present in saidTileRegionGroupEntry.
 33. The medium according to claim 31, wherein saidTileRegionGroupEntry is included in a SampleGroupDescriptionBox forgiving information about the characteristics of sample groups of thevideo data.
 34. A non-transitory computer-readable storage mediumstoring a program for causing a computer to execute a method comprising:receiving one or more media files comprising (i) a plurality of tiletracks each contains video data of at least one tile region and (ii) aTileRegionGroupEntry to be used to describe a tile region of the videodata, wherein the TileRegionGroupEntry includes a descriptor, when setto 1, indicates that a dependency list is present in saidTileRegionGroupEntry, and when set to 0, indicates that the dependencylist is not present in said TileRegionGroupEntry, and wherein thedependency list includes ‘dependency_tile_count’ indicates a number oftile regions in the dependency list and DependencyTileGroupId that givesa group identifier of a tile region that the tile region depends on; andrepresenting video data of one or more tile regions by referring saidTileRegionGroupEntry.
 35. The medium according to claim 34, wherein theTileRegionGroupEntry further includes a flag regarding whether thedescriptor is to be used for decoding process present in saidTileRegionGroupEntry.
 36. The medium according to claim 34, wherein saidTileRegionGroupEntry is included in a SampleGroupDescriptionBox forgiving information about the characteristics of sample groups of thevideo data.